The IP Multimedia Subsystem (IMS) is an architecture based on the Session Initiation Protocol (SIP) which creates a common platform for enabling a broad range of advanced Internet-based multimedia services and applications on top of a packet switched network.
SIP provides an extensible event mechanism, enabling a specific service or SIP event package delivery, to route a set of state information or one or more notifications complying with a specific requested service from a server to a subscribing client.
IMS presence is one example of a service and a SIP event package that a user can subscribe for in order to obtain information about another users reach ability, availability and/or willingness of communication. The presence service can be used to indicate whether certain users are online or not and if online, whether they are idle or busy. Presence service also allows users to share details of their communication means and capabilities with other users.
One example of a general SIP-based presence architecture in the IMS according to the prior art is illustrated in FIG. 1.
A SIP/IMS network is a network of servers, performing a variety of services in support of the presence service, such as e.g. routing, authentication and compression. When the presence service is realized using IMS, the SIP/IMS network will perform a number of additional functions in support of the presence service, such as, e.g. routing of the SIP signaling between the presence sources, Watchers and a Presence Server (PS), authentication and authorization of the described entities, maintaining of the registration state and providing of charging information.
FIG. 1 shows a Watcher or a Watching client 100, requiring presence information associated with another user. Watcher 100 may get access to requested presence information provided via SIP/IMS network 101 via access network 102. The user of interest to the Watcher 100, is typically referred to as a Presentity 103. Presentity 103 may access the SIP/IMS network via the same access network as the Watcher 100, or as in this case, via another access network 104.
Throughout this document, both the Watcher 100 and the Presentity 103 will be defined as a combination of a user, or an automated function operating on behalf of a user, and a user agent (UA) located in an IMS terminal, such as e.g. a stationary PC, a laptop, a PDA or a cellular telephone, and adapted to contribute to the execution of a number of services, each of which is identified by a SIP event package.
The IMS network consists of conventional IMS nodes, such as Proxy Call Session Control Functions 105, 106 (P-CSCF's), a P-CSCF being the first point of contact between an IMS terminal and the SIP/IMS network, Serving Call Session Control Functions 107 (S-CSCF's), a S-CSCF being used as the central node of the signaling plane, and Interrogating Call Session Control Functions 108 (I-CSCF's), providing SIP proxy server functionality, as well as conventional databases, i.e. one or more Home Subscriber Servers 109 (HSS), being the central repository for user-related information, and, in case the network comprises more than one HSS, a Subscriber Location Function 110 (SLF), responsible for mapping user's addresses to an appropriate HSS.
In addition to the nodes mentioned above, the IMS network also typically comprises a plurality of Application Servers (AS's), which are SIP entities that hosts and executes different types of services to authorized users. FIG. 1 comprises two AS's, namely a Presence Server 111 (PS), which may be responsible for managing a presence service, and a Presence Source 112, which is an entity responsible for providing updated presence information to authorized Watchers via the PS 111 on behalf of a Presentity.
The network also comprises a Resource List Server 113 (RLS). An RLS is a functional entity that accepts and manages subscriptions to presence lists, which enables a Watcher to subscribe to presence information of multiple entities using only one single subscription transaction, thereby saving not only bandwidth, but also reducing the power consumption of the Watchers UE's.
Although FIG. 1 only comprises one Presence Source, there are typically a plurality of different Presence Sources available at an IMS network, each of which provides presence information of different categories to one or more Presence Server. It is also to be understood that a typical IMS network may comprise additional CSCF nodes of the types already mentioned, as well as other types of nodes which have been omitted, since they are of no relevant importance to the understanding of the authorization mechanism being the scope of this document.
Another example of a service type being of interest for the described mechanism is the support of XML Configuration Access Protocol (XCAP) changes. XCAP is a generic protocol that can be used for a number of purposes related to the configuration of XML documents stored in a server. This may include, e.g. updating of preferences, presence lists, privacy, or authorization policies.
Notifications, provided to a Watcher according to a requested SIP event package, comprising e.g. presence information are not SIP traffic control signaling. The same channel, i.e. the SIP control signaling channel, is, however, used both for the transmission of notifications, and for the transmission of the SIP traffic control signaling.
Not only can a presence notification, an XCAP document, or any other type of notification be quite large. This type of information can also arrive at any time, and, thus, notifications according to a SIP event package may cause interference problems with the normal SIP traffic control signaling.
In addition, since SIP traffic control signaling often has a higher priority than a media connection, notifications may be exposed to delays, or, during unfavorable conditions, even interruptions.